Reverse Code Engineering RCE CD +sandman 2000

home *** CD-ROM | disk | FTP | other *** search

/ Reverse Code Engineering RCE CD +sandman 2000 / ReverseCodeEngineeringRceCdsandman2000.iso / RCE / Library / +ORC / Orc pac 3 / HOWTO32.TXT < prev next >

Wrap

Text File | 2000-05-25 | 21.7 KB | 453 lines

HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 3.2: hands on, paper protections (2) --------------------------------------------------------------------------- [TOP.EXE] [F19.EXE] [POPULOUS.EXE] [MAP.EXE] -------------------------------------- You have seen in the previous lesson that the use of a password protection, independently of the coding and hiding methods used to store them in memory, implies the use of a comparing procedure with the password that the user types in. You therefore have many options to begin your cracking work: - find the location of the user password - find the "echo" in memory of the real password - find the routine that compares both - find the passwords hideout and encryption type - find the go_ahead_nice_buyer exit or jump - find the beggar_off_ugly_copier exit or jump just to name the more obvious ones. In order to make things more difficult for us crackers, the protectionists have devised many counter-strategies, the more obvious ones being: - keeping the various part of the store/compare/hide routines well apart in code (no match for zen-cracking); - filling these routines with "bogus" compares, bogus jumps and bogus variables, in order to make things more difficult for the crack (no match for decent crackers); - disseminating the code with anti-debugger tricks, like INT_3 instructions or jumps in and out protected mode (no match for our beloved [Soft-Ice]); - trying to eliminate the need for passwords altogether letting the user input "one letter" or "one number" or "one image" as answer to some variable question. In this lesson I'll teach you how to crack these "passletters" protection techniques. Let's first resume the "uses" of a password protection: PASSWORDS AS PERMISSION TO ACCESS These passwords serve to acknowledge that a legitimate user is using the program. This is the type of password that you'll find, for example, protecting your user account on Compuserve, on Networks or even in ATM machines used by banks or corporations. These require a little hardwiring to crack: ATM passnumber protection schemes rely on an answer from the central computer (they do NOT verify only the three magnetic areas in the magnetic strip on the card). The lines between ATM's & their hosts are usually 'weak' in the sense that the information transmitted on them is generally not encrypted in any way. (Some banks use encrypted information, but this is fairly easy to crack too). So for ATMs you should do the following 1) cross over the dedicated line between the ATM and the host; 2) insert your computer between the ATM and the host; 3) Listen to the "normal" messages and DO NOT INTERFERE YET; 4) Try out some operations with a legal card, make some mistakes, take note of the various codes; 5) When you are ready insert a fraudulent card into the ATM. Now the following happens: - the ATM sends a signal to the host, saying "Hey! Can I give this guy money, or is he broke, or is this funny card invalid?"; - the microcomputer intercepts the signal from the host, discards it, sends on the "there's no one using the ATM" signal; - the host gets the "no one using" signal and sends back its "good, keep watching out if somebody comes by, and for God's sake don't spit out any money on the street!" signal to the ATM; - the microcomputer intercepts this signal (again), throws it away (again), and sends the "Wow! That guy is like TOO rich! Give him as much money as he wants. In fact, he's so loaded, give him ALL the cash we have! He is a really valued customer." signal. - the ATM obediently dispenses cash till the cows come home. All this should be possible, but as a matter of fact it has not much to do with cracking, unless there is a special software protection on the line... so if you want to work on ATMs contact our fellow phreakers/hackers and learn their trade... and please remember to hack only cash dispenser that DO NOT HAVE a control camera :=) PASSWORDS AS REGISTRATION This type of password is often used in shareware programs. When you register the shareware program, you are sent a password that you use to upgrade your shareware program to a complete and more powerful version. This method, used frequently for commercial applications, has recently been used quite a lot by many windows applications that come "crippled" on the magazines cover CD-roms, requiring you to telephone a hot line (and paying) in order to get the "unique key" to unlock the "special protection". It's all bullshit: we'll learn in the "how to crack windows" lessons how easy it is to disable the various routines that verify your entry. PASSWORDS AS COPY PROTECTIONS This type of password is often used for games and entertainment software. The password query does not usually appear any more at the start of the program, or as the program is loading. Instead, the password query appears after one or more levels are completed (this innovation was pioneered by "EOB I" and the "Ultima" series) or when the user reloads a saved game or session. DONGLE PASSWORDS A few extremely expensive programs use a dongle (also called an hardware key). A dongle is a small hardware device containing a password or checksum which plugs into either a parallel or a serial port. Some specially designed dongles even include complete program routines. Dongles can be cracked, but the amount of work involved is considerable and the trial and error procedure currently used to crack them via software is extremely tedious. It took me more than a week to crack MULTITERM, Luxembourger dongle protected program. The quickest method to crack dongle protected programs, involves the use of pretty complicated hardware devices that cannot be dealt with here. I myself have only seldom seen them, and do not like at all to crack dongles via software, coz it requires a huge amount of zen thinking and of luck and of time. If you want more information on the hardware way to crack dongles, try to contact the older ones on the appropriate web sites, they may even answer you if you are nice, humble and really technically interested. The obvious principle, that applies to the software password types mentioned above is the following: The better the password is hidden, and the better it is encrypted, the more secure the program will be. The password may be - encrypted and/or - in a hooked vector and/or - in an external file and/or - in a SMC (Self modifying code) part Let's finally inspect the common "ready_made" protection schemes (used by many programmers that do not program themselves): * password read in * letters added to a key to be entered * complement of the letters formed xoring with 255 * saved key (1 char) * saved password (256 chars) * saved checksum (1 char), as protection, against simple manipulations * generating file PASSWORD.DAT with password, to be inserted inside a different file than the one containing the calling routine Now the lazy programmer that wants to "protect" his program searches first the file where the password is stored, then loads the key, the password and the checksum. He uses a decrypt procedure to decrypt the password and a check_checksum procedure to check whether the password was modified. All this is obviously crackabe in few seconds. [PASSWORD ACCESS INSIDE THE SETUP] Some computers have a password protected access INSIDE the Setup (at the beginning), the protection scheme does not allow a boot with a floppy and does not allow a setup modify. In these cases the only possible crack is an old hack method: * open the PC * find on the motherboard a small jumper (bridge) with the words "Pw" * take it away * PC on * run the setup with F1 or Del (depending from the BIOS) (the protection will not work any more) * deactivate inside the setup the option password * PC off * put the small jumper (bridge) back again * close the PC * PC on, cracked (if you want to be nasty you could now use the setup to set YOUR password) If you want to know more about access refuse and access denying, encryption and locking of the FAT tables, get from the web, and study, the (very well written) code of a virus called "Monkey", that does exactly this kind of devastation. Virus studying is, in general, very useful for cracking purposes, coz the virus'code is at times - very well written (pure, tight assembly) - using concealing techniques not much different from the protection schemes (often far superior) - using the most recent and best SMC (self modifying code) tricks But, and this is very important, do not believe that the protection schemes are very complicated! Most of the time the protection used are incredibly ordinary: as a final example of our paper protection schemes, let's take a program released not long ago (1994), but with a ridiculous protection scheme: TOP (Tiger on the prowl) a simulation from HPS. Here the cracking is straightforward: - MAP(memory_usage) and find main_sector - type "AAAA" as password - (s)earch main_sector:0 lffff "AAAA" - dump L80 "AAAA" location -40 (gives you a "wide" dump), this gives you already the "echo" of the correct password - breakpoint on memory read & write to "AAAA" location and backtrace the complete main_sector it's done! Here the code_lines that do protect TOP: 8A841C12 MOV AL,[SI+121C] move in AL first user letter 3A840812 CMP AL,[SI+1208] compare with echo 7402 JZ go_ahead_nice_buyer EB13 JMP beggar_off_ugly_cracker Now let's quickly crack it: ------------------------------------------------ CRACKING TOP.EXE (by +ORC, January 1996) ren top.exe top.ded symdeb top.ded - s (cs+0000):0 Lffff 8A 84 1C 12 3A 84 xxxx:yyyy (this is the answer of the debugger) - e xxxx:yyyy+2 08 (instead of 1C) - w - q ren top.ded top.exe ------------------------------------------------- And you changed the MOV AL, [SI+121C] instruction in a MOV AL, [SI+1208] instruction... it is now reading the ECHO instead of the characters you typed in... no wonder that the ECHO does compare exactly with itself... and you pass! "SOMETHING FISHY UNDER COVERS" Back to the "Passletter" type of password protected programs. Let's take as an example the protection used in a game of 1990: "F19", where the protection scheme asks you to identify a particular plane's silhouette. This kind of protection is used in order to avoid the use of memory locations where the passwords are stored: we saw in the first part of our "passwords hands on" how easy it is to crack those schemes. To crack this kind of protection, you could try a technique know as "memory snuffing". The protected program, START.EXE, install itself first at location xxxx:0000 with a length of 6C62 bytes, but proceeds to a relocation of its modules (with some SMC, self modifying code parts) in different locations. What does all this mean? Well, this could mean quite many things... the most important one for crackers is that the protection code will probably snap way ahead of the actual user input phase. Now you 'll quickly find out that the routine determining (randomly) which plane is being chosen, leaves the progressive number of this plane in one memory location: (imc) 43CD:DADA. This brings us to the random triggering mechanism: E87FAF CALL random_seed 83C402 ADD SP,02 8946E8 MOV [BP-18],AX and ds:(BP-18) is the location you are looking for Now, every time this random triggers, you get a different number (00-x14) in this location, corresponding to the different plane the user should choose. The random seed routine, evidently, comes back with the random seed in AX... what we now need is to zero it: the user will always have to choose the same plane: "plane 0", and he will have given the correct answer. Note how elegant all this is: we do not need to interfere with the whole mouse pointing routines, nor with the actual choosing of the planes... the random seed may choose whatever plane it wishes... the memory location for this choice will always report the (legitimate) choice of zero. So, let's quickly crack this program: --------------------------------------------------- CRACKING "F19" [START.EXE] (by +ORC, January 1996) ren start.exe start.ded <- let's have a dead file symdeb start.ded <- let's debug it - s cs:O lffff 83 C4 02 89 46 E8 <- search ADD SP,02 xxxx:yyyy <- debugger's answer - e xxxx:yyyy 58 [SPACE] 31 [SPACE] C0 [SPACE] - w <- write the crack - q <- back to the OS ren start.ded start.exe <- re-write the exe ---------------------------------------------------- You just transformed the instruction you searched for 83C402 ADD SP,+02 in the following sequence: 58 POP AX <- respecting ADD SP,+02 31C0 XOR AX,AX <- xoring to zero (the POP AX instruction increments the stack pointer by 2, in order to respect the previous ADD SP,+02). Well, nice. It's getting easier, isnt'it? Now let's take as example a protection that has no "echo" in memory. (At the beginning this was a smart idea: "the cracker won't find the correct password, 'coz it's not there, ah!". We'll now therefore crack one of the first programs that used this scheme: [Populous.exe], from Bullfrog. [POPULOUS.EXE] A old example of the protection scheme "password that is not a password" can be found in [Populous.exe], from Bullfrog. It's a very widespread program, and you'll surely be able to find a copy of it in order to follow this lesson. The program asks for the identification of a particular "shield", a combination of letters of various length: the memory location were the user password is stored is easily found, but there is (apparently) no "echo" of the correct password. You should be able, by now, to find by yourself the memory location were the user password is stored. Set a breakpoint memory read & write on this area, and you 'll soon come to the following section of code: F7AE4EFF IMUL WORD PTR [BP+FF4E] <- IMUL with magic_N° 40 INC AX 3B460C CMP AX, [BP+0C] 7509 JNZ beggar_off_ugly_copier 8B460C MOV AX, [BP+0C] A3822A MOV [2A82], AX E930FE JMP nice_buyer 817E0C7017CMP WORD PTR[BP+0C],1770 <- beggar_off I don't think that you need much more now... how do you prefer to crack this protection scheme? Would you choose to insert a MOV [BP+0C], AX and three NOPS (=6 bytes) after the IMUL instruction? Wouldn't you rather prefer the more elegant JMP to nice_buyer instruction at the place of the JNZ beggar_off? This solution has less nops: remember that newer protection schemes smell NOPs_patches!). Yeah, let's do it this way: --------------------------------------------------- CRACKING [Populous.exe] (by +ORC, January 1996) ren populous.exe populous.ded <- let's have a dead file symdeb populous.ded <- let's debug it - s cs:O lffff F7 AE 4E FF <- the imul magic_N° xxxx:yyyy <- debugger's answer - e xxxx:yyyy+4 EB [SPACE] 03 <- JMP anyway - w <- modify ded - q <- back to the OS ren populous.ded populous.exe <- let's re-have the exe ---------------------------------------------------- This time was easy, wasnt'it? Now you are almost ready with this course... let's crack a last application, a memory utility that is very widespread, very good (the programmers at Clockwork software are Codemasters), very useful for our purposes (you'll use it later to crack a lot of TSR) and, unfortunately for Clockworkers, very easy to crack at the level you are now. But, Hey! Do not forget that you would have never done it without this tutorial, so do the following: look toward east from your window, sip a Martini-Wodka (Two blocks of ice first, 1/3 dry Martini from Martini & Rossi, 1/3 Moskovskaia Wodka, 1/3 Schweppes indian tonic) and say three times: Thank-you +ORC!. [MAP.EXE] Let's now go over to one of the best TOOLS for mapping your memory usage that exist: MAP.EXE (version 2) from the masters at Clockwork software. The usage of this tool has been recommended in Lesson 2, and you should learn how to crack it, coz it comes with an annoying nag-screen ("Nigel" screen). In [Map.exe] this ubiquitous "Nigel" screen appears at random waiting for a random amount of time before asking the user to press a key which varies every time and is also selected at random. The use of a single letter -mostly encrypted with some XOR or SHR- as "password" makes the individuation of the relevant locations using "snap compares" of memory much more difficult. But the crack technique is here pretty straightforward: just break in and have a good look around you. The INT_16 routine for keyboard reading is called just after the loading of the nag screen. You 'll quickly find the relative LODSB routine inside a routine that paints on screen the word "Press" and a box-edge after a given time delay: B95000 MOV CX,0050 2EFF366601 PUSH CS:[0166] 07 POP ES AC LODSB ... You could already eliminate the delay and you could already force always the same passletter, in order to temperate the effects of the protection... but we crack deep!: let's do the job and track back the caller! The previous routine is called from the following section of the code: 91 XCHG AX,CX 6792 XCHG AX,DX 28939193 SUB [BP+DI+9391],DL 2394AA94 AND DX,[SI+94AA] 2EC7064B880100 MOV WORD PTR CS:[884B],0001 2E803E5C0106 CMP BYTE PTR CS:[015C],06 7416 JZ ret <- Ha! jumping PUSHa & POPa! 505351525756 PUSH the lot E882F3 CALL 8870 2E3B064B88 CMP AX,CS:[884B] 7307 JAE after RET <- Ha! Not taking the RET! 5E5F5A595B58 POP the lot C3 RET ... <- some more instructions E86700 CALL delay_user BE9195 MOV SI,9591 2E8B3E255C MOV DI,CS:[5C25] 83EF16 SUB DI,+16 2E8A263D01 MOV AH,CS:[013D] 50 PUSH AH E892C7 CALL routine_LODSB <-- HERE! B42C MOV AH,2C CD21 INT 21 <- get seconds in DH 80E60F AND DH,0F 80C641 ADD DH,41 58 POP AX 8AC6 MOV AL,DH 83EF04 SUB DI,+4 AB STOSW E85A00 CALL INT_16_AH=01 B400 MOV AH,00 CD16 INT 16 24DF AND AL,DF <- code user's letter_answer 3AC6 CMP AL,DH <- pass_compare 75F3 JNZ CALL INT_16_AH=01 E807F3 go_ahead You just need to look at these instructions to feel it: I think that unnecessary code segments (in this case protections) are somehow like little snakes moving under a cover: you cannot easily say what's exactly going on yet, but you could bet that there is something fishy going on. Look at the code preceding your LODSB routine call: you find two JUMPS there: a JZ ret, that leaves a lot of pusha and popa aside, and a JAE after RET, that does not take the previous ret. If you did smell something here you are thoroughly right: The first JZ triggers the NIGEL screen protection, and the second JAE does THE SAME THING (as usual, there are always redundances, exactly as there are a lot of possibilities to disable a single protection). Now you know... you can disable this protection at different points: the two easiest blueprints being 1) to change 7416 (JZ ret) in a EB16 (JMP ret anyway) 2) to change 7307 (JAE after ret) in a 7306 (JAE ret). We have not terminated yet: if you try locating this part of the code in order to change it, you won't have any luck: it's a SMC (Self modifying code) part: it is loaded -partly- from other sections of the code (here without any encryption). You must therefore first of all set a breakpoint on memory range; find out the LODSW routine; find out the real area; dump that memory region; find out a search sequence for the "dead" code... and finally modify the "dead" program. Now let's quickly crack it: ------------------------------------------------ CRACKING MEM.EXE (version 2) (by +ORC, January 1996) ren map.exe map.ded symdeb map.ded - s (cs+0000):0 Lffff 74 16 50 53 51 52 57 xxxx:yyyy <- this is the debugger's answer - e xxxx:yyyy EB - w - q ren map.ded map.exe ------------------------------------------------- Now you have done it, NIGEL has been cracked! Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. E-mail +ORC +ORC an526164@anon.penet.fi